Automating tasks is one of the best ways to keep a system running smoothly. If you take
all the repetitive system administration commands you need to run regularly and have them
run in background without your direct involvement, system administration becomes much less
onerous and bothersome. The utilities cron and at were developed to help make your job
easier. Both allow you to execute commands automatically at specified times, without
bothering you.
The cron (short for chronograph) utility is designed to allow commands to execute at
specific times without anyone directly initiating them. Linux loads cron as a clock daemon
when the system starts up. (The cron utility is usually run from an rc file entry; you can
disable it by commenting out the line that starts cron.) When operating, cron reads the
days and times it is supposed to execute a task from a file called the crontab file.
Whenever one of the crontab file's day and time specification entries matches the
system's date and time, the cron daemon executes the command. The cron utility doesn't
just execute the task once; the task is run again whenever the specified day and time
match the system day and time. The task continues to be run until you terminate the cron
utility or modify the crontab file. The automatic execution of tasks means that cron is
ideal for automating regular system administration tasks such as tape backups, database
reorganization, and general file cleanups (such as emptying log files and queues).
On most systems, access to cron is limited to the system administrator, although you
can easily activate it for some or all users on your system. System administrators control
who can send processes to be executed by cron through one of two different files, often
called /usr/lib/cron/cron.allow or /usr/lib/cron/cron.deny. Many Linux systems use the
names /etc/cron.d/cron.allow and /etc/cron.d/cron.deny. Both files have one username
(which matches the entry in /etc/passwd) per line.
The file /usr/lib/cron/cron.allow (or /etc/cron.d/cron.allow) can contain a list of all
usernames that are allowed to use cron. For example, the file
tparker yvonne bill
allows only the logins tparker, yvonne, and bill (as well as the superuser) to submit
anything to cron.
The file /usr/lib/cron/cron.deny can contain a list of usernames that are not allowed
to use cron. For example, the file
walter anne
allows everyone except the logins walter and anne to use cron.
By using one of these optional files, system administrators can control cron usage. If
neither the cron.allow or cron.deny files exist, only the superuser (root) can submit
processes to cron. To allow all users to use cron, create an empty cron.deny file.
To instruct cron to process commands at particular days and times, you use a utility
called crontab. The crontab program reads a file that contains the details of what you
want cron to do and queues it. In addition, crontab performs several other administrative
tasks, such as displaying your current cron task list, removing the list, and adding new
tasks to the list.
The file that crontab reads to determine what you want to submit to cron is usually
named crontab for convenience, although you can call it anything. The crontab utility has
a command option that allows you to specify the filenameyou want it to use. If you don't
use this option, the crontab utility reads the default filename, crontab.
The crontab instruction file has a simple structure. The file consists of one complete
line for each process to be submitted that specifies when to run the process and what
command to execute. The format of each line is as follows:
minute hour day-of-month month-of-year day-of-week command
An example two-line extract from a crontab file looks like the following:
20 1 * * * /usr/bin/calendar - 0 2 * * * /bin/organize_data
Each line in the crontab file has six columns separated by whitespace (spaces or tabs).
The columns, from left to right are as follows:
This rather strange (at first glance) format is necessary to enable you to completely
specify when a process is to run. Without the five different categories for days and time,
you couldn't uniquely specify any event that occurs one or more times a month. These
columns are quite easy to complete.
The last column contains the command or script filename that is to be executed. A
script that is to be executed can have many lines and call other scripts, or it can be
only a single line. The first process is initiated when the crontab file matches the day
and time. It is important to provide an absolute pathname to the command (even if it's in
your PATH), as the cron jobs do not inherit your environment variables and thus don't know
where to look for commands. Also, you must have execute permission for the utility or
script. If you are submitting crontab files as a user (not superuser), you must have file
permissions or ownership set to allow you normal access, as cron executes the processes as
though you owned them.
Each time and day column in the crontab file can contain a single number anywhere in
the range of valid numbers, two numbers separated by a minus sign to show an inclusive
range (such as 1-5 to show one through five), a list of numbers separated by commas to
mean all of the values explicitly specified, or an asterisk meaning all legal values.
Look at the following sample lines of a crontab file to see how this file works:
20 1 * * * /usr/bin/calendar - 0 2 1 * 0 /bin/organize_data 10,30,50 9-18 * * * /bin/setperms
This example specifies three different processes. The first command is
/usr/bin/calendar - (the hyphen is an important part of the command). This process is
executed at 20 minutes past one in the morning (cron uses a 24-hour clock) every day of
the week and each day of the year. The asterisks mean all values(every day).
At 2:00AM, a script file called /bin/organize_data is executed on the first day of
every month (the 1 in the third column) and every Sunday (the 0 in the fifth column). If
the first day is a Sunday, it executes only once, of course. The third line shows that a
script called /bin/setperms runs at 10, 30, and 50 minutes past the hour every hour
between 9:00AM and 6:00PM (18:00), every day of the week.
The entries in a crontab file do not have to be in any special order. As long as each
entry is on a line by itself and has all six fields specified properly, cron organizes the
information for its own use. If you have an error in the crontab file, cron mails you a
notice of the problem when it processes your file. (This notice can be annoying if you
have the entry with the error set to execute often because cron mails you each time it
tries to execute the entry and finds a problem. Your mailbox quickly gets filled with cron
error messages.)
Keep the crontab files in your home directory and name them crontab, unless you want to
have several versions of the files, in which case you can use any naming convention you
want. Keeping the names simple helps you identify which file you want cron to execute.
After you write your crontab file, you can submit it for cron to execute. When you
submit a crontab file, a copy of the file is made and kept in a cron directory, usually
/usr/spool/cron/crontabs. The file has the name of the submitting user. A crontab file
submitted by yvonne, for example, has the name /usr/spool/cron/crontabs/yvonne. Any
crontab files submitted by the superuser usually have the name root.
To submit your crontab file to cron, use the crontab command followed by the name of
the file with the cron commands in it. For example, the command
crontab crontab
submits the file called crontab in the current directory to cron. If you had previously
submitted a cron file, it is removed and the new file is used instead.
Always submit a change to cron using the crontab file and an edited ASCII file. Never make changes to the file in /usr/spool/cron/crontabs; the changes will not be read by cron and can potentially mess up any existing cron tasks.
You can see what you have submitted to cron by using the -l (list) option. This option
shows all the crontab entries the cron utility knows about (essentially displaying the
contents of the file with your username from /usr/spool/cron/crontabs). For example, the
command
crontab -l
shows all cron tasks for the user who submits the command.
To remove your crontab file and not replace it, it use the -r (remove) option. This
option erases the file with your filename from the /usr/spool/cron/crontabs directory. The
syntax for this command is as follows:
crontab -r
Finally, you can call up your current cron file and start an editor (the default editor
as defined by your environment variables or a system default variable) by using the -e
(editor) option. When you issue the command
crontab -e
crontab reads your existing crontab file and loads it into the default editor (such as
vi). When you save the edited file, it is submitted to cron automatically.
Changes to the crontab file are usually effective within five minutes at most, as cron
reads the contents of the /usr/spool/cron/crontab file at least once every five minutes
and often more frequently (most Linux systems have cron check the directories every
minute). Because you have to wait for cron to check the contents of the crontab file,
execution of a process you have submitted to cron can sometimes be delayed by a few
minutes, so don't rely on cron to be exactly on time. The more heavily loaded a system is,
the greater the delay in execution.
On some systems, system administrators can log all cron usage by modifying an entry in
the file /etc/default/cron. One line in the file should contain the variable CRONLOG. If
you set the value equal to YES, cron logs every action it takes to the file
/usr/lib/cron/log. Not all versions of Linux allow cron logging. If you do enable cron
logging, check the log file frequently as it can grow to a large size quite quickly.
The crontab file can contain any type of command or shell script, as long as the line
is valid (in other words, it could be executed from the shell prompt). A common problem
with many shell commands is the generation of output, especially error messages, which is
mailed to you and can clog up your mailbox quickly. For this reason, if you anticipate
error message output (from a compiler, for example), you can redirect the output to
/dev/null. For example, the command
0 * * * * date > /tmp/test1 2>/dev/null
sends the output of the date command to a file called /tmp/test1 every hour and sends
any error messages to /dev/null (which essentially discards such messages). You can do the
same with the standard output, if you want, or you can redirect it elsewhere. For example,
the cron command
30 1 * * * cat /usr/tparker/chapt* > /usr/tparker/archive/backup
concatenates all the files starting with chapt in /usr/tparker into one large file
called /usr/tparker/archive/backup. Again, you can redirect the the standard output.
You can also do piping in the crontab file. For example, if you have a list of users
who are logged in the system during the day in the file /tmp/userlist, you can have a
crontab entry that looks like the following:
0 1 * * * sort -u /tmp/userlist | mail -s"users for today" root
This line sorts the output of /tmp/userlist so that there is only one entry for each
user (the -u or unique option) and mails it to root.
An important point to remember with cron is that all commands are executed, by default,
in the Bourne shell (or bash, if it is the sh equivalent on your system). If you use C
shell commands, the cron task will fail.
The at program is very similar to cron, except that at executes a command only once at
a prespecified time and cron keeps executing a command. The format of the at command is as
follows:
at time date < file
You can specify most of the at command parameters in several different ways, which
makes the at command versatile. you can specify the time, for example, as an absolute time
(18:40 or 22:00) or as two digits that are taken as hours (so 10 means ten o'clock in the
morning as a 24-hour clock is the default). You can add an am or pm to the time to make it
clear which you mean, so 10pm is unambiguously in the evening.
The at command handles a few special words instead of time designations. The command
recognizes the words noon, midnight, now, next, and zulu for GMT conversion. (Some at
versions generate an error message if you try to execute a command with the time set to
now.)
The date is an optional field that you use when the time is not specific enough. If you
don't supply a date, at executes the command the next time the specified time occurs. If
you specify a date, at waits until that date to execute the command. You can give the date
as a month's name followed by a day number (May 10) or a day of the week (either spelled
out in full or abbreviated to three characters). You also can specify a year, but this
specification is seldom necessary. As with the time, the at command recognizes two special
words that relate to dates: today and tomorrow (although the word today is redundant as
the command executes today by default if the time is set properly).
The file to be read in as input to the at command can be any file with commands in it.
Alternatively, you can type in the commands and press Ctrl+d when you're finished,
although this method is not recommended due to the high potential for error.
Suppose you have a file called reorg.data with the following commands in it:
/usr/tparker/setperms /usr/tparker/sort_database /usr/tparker/index_database /usr/tparker/clean_up
If you want to execute this file at 8:30PM, issue any one of the following commands:
at 20:30 < reorg.data at 8:30 pm < reorg/data at 20:30 today < reorg.data
Even more variations are possible, but you can see the syntax. If you want to execute
the command on Friday, issue the command in one of these formats:
at 8:30 pm Friday < reorg.data at 20:30 Fri < reorg.data
Some versions of at are even more talented and handle special words. For example, this
command
at 0900 Monday next week < reorg.data
executes the commands next week on a Monday. Not all versions of at can handle these
complex formats, however. Check the man pages to see which formats your version supports,
or just try these formats and see whether you get an error message.
When you submit a program to at for execution, you get back a job identification
number. This number uniquely identifies the at command you just issued. For example, look
at the output from this at command:
$ at 6 < do_it job 827362.a at Wed Aug 31 06:00:00 EDT 1995
In this case, the job ID is 827362.a and the ID is needed to make any changes to the
job.
You can list all the jobs you have queued with at using the -l (list) option. The
output usually tells you when the command is set to execute, but not what the command is:
$ at -l user = tparker job 827362.a at Wed Aug 31 06:00:00 EDT 1995 user = tparker job 829283.a at Wed Aug 31 09:30:00 EDT 1995
Some versions of Linux may support the shorter form of the command with atq (display
the at queue). If you get an error message when you issue the atq command, you have to use
the at -l format.
To remove an at job from the system, you need the job ID and the at -r (remove)
command. For example, the command
at -r 2892732.a
removes the specified job. Linux doesn't return any message to indicate the job has
been canceled, but you will see the job is gone if you list the queue. You can remove only
your own jobs (root can remove any). Some Linux versions support the atrm command as well
as the -r option.
All jobs that are queued to at are kept in the directory /usr/spool/cron/atjobs with
the job ID number as the filename. As with cron, an at.allow and an at.deny file in either
the /usr/lib/cron or /etc/cron.d directory controls who can and can't use at. As with
cron, create an empty at.deny file if you want all users on your system to be able to use
at.
When an at job executes, all output (standard output and error messages) is mailed back
to the username who submitted the job unless it has been redirected. The at command
retains all the environment variables and directory settings of the user. If you look at a
queued job in /usr/spool/cron/atjobs, you see all the variables defined prior to the
command to be executed.
As you have seen, cron and at are quite easy to use. They are also a system
administrator's best friends, as you can automate tiresome tasks like cleaning up
databases, checking disk space, flushing log files, and making tape backups with cron or
at. Although cron and at can't do everything for you, they can handle repetitive tasks
with ease.
Most Linux systems have a number of sample cron files supplied with the operating system. Examine those files (or list the current crontab file while logged in as root) to see what the operating system wants to execute on a regular basis. Use those commands as the starting point and add your own commands. Probably the worst that can happen if you mess up a crontab file is that you will get a lot of mail!
